Federation — identity, roles & access

Sign-in methods — Google · Microsoft · LinkedIn · email & password; organizations can enforce Microsoft Entra ID SSO at org level. Methods attach to the account, not the tenant. ← ID-3, ACC-5

Identity is (email, tenant). An account belongs to exactly one tenant; the same email may hold a separate account per tenant. When an email resolves to several accounts, sign-in offers the account chooser — never a merged session. ← ID-1, ID-2

One federated session. A signed-in RiverSync ID moves between every application it is entitled to without re-authentication. The product switcher lists only entitled apps — gated apps never appear as locked tiles to unentitled accounts. ← ID-4, AUTH-2

Email verification gates org surfaces. Until the address is verified, organization pages render locked with an explain-and-unlock state naming what verification opens. My Account stays reachable. ← ACC-5

Entitlement = tenant-type gate + per-app role grant. The tenant type decides which of the six applications are reachable at all; within reachable apps, an account participates only where it holds a role grant (FED-18). The matrix below is normative. ← AUTH-1, AUTH-2

App reach is per role, not only per tenant. Within a tenant's reachable apps (FED-5), a role holds a grant only in the apps it works in — so two members of one tenant can carry a different set of product tiles. The matrix is normative: a member's product switcher shows exactly its ● apps and nothing else. ← AUTH-1, AUTH-2, AUTH-3

Exactly one role per account per application. A member can be Administrator in Account and Viewer in Portal; no account holds two roles in one app, and there is no role-union mechanic anywhere. ← AUTH-1, AUTH-6

Every tenant owns its role set. Defaults below; tenants create custom roles on the standard Roles page (template-based: start from Viewer / Editor / Administrator / blank) and configure them on Permissions. The riversync tenant's five roles are ordinary configurable roles in this same model. ← AUTH-5, AUTH-7, ACC-2

One fixed-full role per tenant. Customer and partner tenants: Owner. The riversync tenant: admin. The fixed role always holds every permission, renders locked-on in every matrix, and cannot be restricted or deleted. ← AUTH-7, ACC-2

Permission catalogs are per application. Each app carries its own catalog, grouped by domain; the Permissions surface is a role × permission matrix per app, with the fixed-full role's column locked on. Apps the tenant cannot reach render as locked chips naming the reason. ← AUTH-3, AUTH-7, ACC-2

Scope narrows, never widens. The matrix default applies organization-wide; a region or site override replaces it for that scope with an equal-or-narrower set. Departments do not drive permission scope (open question in SPEC-APP-ACC). ← ACC-2

Partner access is customer-granted, per link. Four scope switches — telemetry · service tickets · sites & visit info · invoices & agreements — optionally limited by region, set by the customer on the partner detail page, changeable or revocable at any time, effective immediately. A partner's queries are bounded by the grant and by its covered devices; partners never see uncovered devices or other partners' coverage. ← PRT-3, PRT-7, PAR-1

Every cross-tenant action is audited and attributed to the acting organization — partner actions land in the customer's audit log under the partner org's name; RiverSync users’ actions under RiverSync's. ← PRT-4, PAR-5

RiverSync view-as sessions. RiverSync users act inside a customer tenant only through a view-as session: gated by the "Start a view-as session" permission (Support & service group), announced by a persistent banner, every action logged in both the customer's audit log and the RiverSync trail. Two planes, separate sessions: account-side (Account portal) and hub-side (the customer's Portal from the Operations console). ← TEN-3, ADM-5

RiverSync factory default. Factory telemetry and engineer dispatch are on for every device by default — not customer-manageable, never represented as a partner link, always audited. ← PRT-6

The rules below are normative for every prototype and for production. Each names the surface it governs; a screen that contradicts one is a bug, not a variation. ← AUTH-2, ACC-5, PRT-8, PRT-12, PRT-13, ADM-5

Identity is ASP.NET Core Identity 10, extended — never replaced. Accounts, roles, the user-role join, external logins, claims and tokens are the framework's seven AspNet* tables (Guid keys). ApplicationUser : IdentityUser<Guid>, ApplicationRole : IdentityRole<Guid> and ApplicationUserRole : IdentityUserRole<Guid> carry the RiverSync extension columns; Tenant, Organization, Application, Permission and RolePermission are extension entities with no Identity equivalent. ← ID-1…4, AUTH-1…7

Prototypes resolve access from the signed-in persona, never per page. The Tweaks panel ("Signed in as" → tenant · partner type · role) signs you in as one of the members below; every surface — switcher tiles, locked chips, nav, matrices — must derive from that persona through the layers in §1. This table is the canonical persona set; new prototypes reuse it, never invent parallel members.

The prototype exposes the persona as Tweaks — these choices and no others. The Tweaks panel (toolbar “Tweaks” toggle) is the single control for who you are signed in as; its options are exactly the dimensions of the access model (§1), so changing one re-resolves every surface live (switcher, nav, matrices, locks). No screen offers a parallel persona control. The available choices are normative for every prototype. ← AUTH-1, AUTH-2, ACC-5